深度剖析 HDFS

发表于 | 分类于

本文整理自：https://www.cnblogs.com/Xmingzi/p/6032415.html

前言

大数据底层技术的三大基石起源于Google在2006年发表的三篇论文：GFS、Map-Reduce、Bigtable，其中 GFS 和 Map-Reduce 直接支持了 Apache Hadoop 项目的诞生，Bigtable 催生了 NoSQL 这个崭新的数据库领域。

为弥补 Map-Reduce 处理框架高延时的缺陷，Google 在 2009 年后推出的Dremel 促使了实时计算系统的兴起，以此引发大数据第二波技术浪潮。一些大数据公司纷纷推出自己的大数据查询分析产品，如：Cloudera 开源了大数据查询分析引擎 Impala，Hortonworks 开源了 Stinger，Fackbook 开源了 Presto、UC Berkeley AMPLAB 实验室开发了 Spark 计算框架。

所有这些技术和产品的数据来源均基于 HDFS，而 HDFS 作为一个分布式文件存储系统，最基本的就是其读写操作。

目录

  • HDFS 名词解释
  • HDFS 架构
  • NameNode（NN）
  • Secondary NameNode
  • HDFS 写文件
  • HDFS 读文件
  • Block 持续化结构

HDFS 名次解释

  • Block：在 HDFS 中，每个文件都是采用的分块的方式存储，每个 Block 放在不同的 DataNode 上，每个 Block 的标识是一个三元组（block id， numBytes，generationStamp），其中 block id 是具有唯一性，具体分配是由 NameNode 节点设置，然后再由 DataNode 上建立 block 文件，同时建立对应 block meta 文件
  • Packet：在 DFSclient 与 DataNode 之间通信的过程中，发送和接受数据过程都是以一个 Packet 为基础的方式进行
  • Chunk：中文名字也可以称为块，但是为了与 Block 区分，还是称之为Chunk。在 DFSClient 与 DataNode 之间通信的过程中，由于文件采用的是基于块的方式来进行的，但是在发送数据的过程中是以 Packet 的方式来进行的，每个 Packet 包含了多个 Chunk，同时对于每个 Chunk 进行checksum 计算，生成 checksum bytes

小结

  • 一个文件被拆成多个block持续化存储（block size 由配置文件参数决定） 思考： 修改 block size 对以前持续化的数据有何影响?
  • 数据通讯过程中一个 block 被拆成 多个 packet
  • 一个 packet 包含多个 chunk

Packet结构与定义：Packet分为两类，一类是实际数据包，另一类是heatbeat包。一个Packet数据包的组成结构，如图所示

上图中，一个 Packet 是由 Header 和 Data 两部分组成，其中 Header 部分包含了一个 Packet 的概要属性信息，如下表所示：

  • Data 部分是一个 Packet 的实际数据部分，主要包括一个 4 字节校验和（Checksum）与一个 Chunk 部分，Chunk 部分最大为 512 字节
  • 在构建一个 Packet 的过程中，首先将字节流数据写入一个 buffer 缓冲区中，也就是从偏移量为 25 的位置（checksumStart）开始写 Packet 数据Chunk 的 Checksum 部分，从偏移量为533的位置（dataStart）开始写Packet数据的Chunk Data部分，直到一个Packet创建完成为止。
  • 当写一个文件的最后一个 Block 的最后一个 Packet 时，如果一个 Packet 的大小未能达到最大长度，也就是上图对应的缓冲区中，Checksum 与 Chunk Data 之间还保留了一段未被写过的缓冲区位置，在发送这个Packet 之前，会检查 Chunksum 与 Chunk Data 之间的缓冲区是否为空白缓冲区（gap），如果有则将 Chunk Data 部分向前移动，使得 Chunk Data 1 与 Chunk Checksum N 相邻，然后才会被发送到 DataNode 节点。

HDFS 架构

HDFS 主要包含四类角色：Client、NameNode、SecondaryNameNode、DataNode

  • HDFS Client：系统使用者，调用 HDFS API 操作文件，与 NameNode 交互获取文件元数据，与 DataNode 交互进行数据读写（注意：写数据时文件切分是由 Client 完成的）；
  • NameNode：Master 节点（也称元数据节点），是系统唯一的管理者。负责元数据的管理（名称空间和数据块映射信息），配置副本策略，处理客户端请求等；
  • DataNode：Slave 节点（也称数据存储节点），存储实际的数据，执行数据块的读写，汇报存储信息给NameNode；
  • SecondaryNameNode：小弟角色，分担大哥 NameNode 的工作量，是NameNode 的冷备份，合并 fsimage 和 fsedits 然后再发给 NameNode，注意：在 Hadoop 2.x 版本，当启用 HDFS HA 时，将没有这一角色。

热备份：b 是 a 的热备份，如果 a 坏掉。那么 b 马上运行代替 a 的工作。
冷备份：b 是 a 的冷备份，如果 a 坏掉。那么 b 不能马上代替 a 工作。但是 b 上存储 a 的一些信息，减少 a 坏掉之后的损失

HDFS 架构原则：

  • 元数据与数据分离：文件本身的属性（即元数据）与文件所持有的数据分离；
  • 主/从架构：一个 HDFS 集群是由一个 NameNode 和一定数目的 DataNode 组成；
  • 一次写入多次读取：HDFS 中的文件在任何时间只能有一个 Writer。当文件被创建，接着写入数据，最后，一旦文件被关闭，就不能再修改；
  • 移动计算比移动数据更划算：数据运算，越靠近数据，执行运算的性能就越好（数据的本地化），由于 HDFS 数据分布在不同机器上，要让网络的消耗最低，并提高系统的吞吐量，最佳方式是将运算的执行移到离它要处理的数据更近的地方，而不是移动数据。

NameNode

NameNode 是整个文件系统的管理节点，也是 HDFS 中最复杂的一个实体，它维护着 HDFS 文件系统中最重要的两个关系：

  1. HDFS 文件系统中的文件目录树，以及文件的数据块索引，即每个文件对应的数据块列表；
  2. 数据块和数据节点的对应关系，即某一个数据块保存在那些数据节点的信息；

第一个关系即目录树、元数据和数据块的索引信息会持久化到物理存储中，具体实现是保存在命名空间的镜像 fsimage 和编辑日志 edits 中。注意：在 fsimage 中，并没有记录每一个 block 对应到哪几个 DataNode 的映射信息；

第二个关系并不会持久化存储，它是在 NameNode 启动后，每个 DataNode 对本地磁盘进行扫描，将本 DataNode 上保存的 Block 信息汇报给 NameNode。NameNode 在接收到每个 DataNode 的块信息汇报后，将接收到的块信息，以及其所在的 DataNode 信息等保存在内存中。HDFS 就是通过这种块信息汇报的方式来完成 Block -> DataNodes list 的映射表构建。

fsimage 记录了自最后一次检查点之前 HDFS 文件系统中所有目录和文件的序列化信息；edits 是元数据操作日志（记录每次保存 fsimage 之后到下次保存之间的所有 HDFS 操作）。

在 NameNode 启动时候，会先将 fsimage 中的文件系统元数据信息加载到内存，然后根据 eidts 中的记录将内存中的元数据同步至最新状态，然后将这个新版本的 FsImage 从内存中保存到本地磁盘上，然后删除旧的 EditLog，这个过程称为一个检查点 (checkpoint)。

类似于数据库中的检查点，为了避免 edits 日志过大，在 Hadoop 1.X 中，SecondaryNameNode 会按照时间阈值（比如24小时）或者 edits 大小阈值（比如1G），周期性的将 fsimage 和 edits 合并，然后将最新的 fsimage 推送给 NameNode。而在 Hadoop2.X 中，这个动作是由 Standby NameNode 来完成的。

由此可看出，这两个文件一旦损坏或丢失，将导致整个HDFS文件系统不可用。

在 Hadoop 1.X 为了保证这两种元数据文件的高可用性，一般的做法是将dfs.namenode.name.dir 设置成以逗号分隔的多个目录，这多个目录至少不要在一块磁盘上，最好放在不同的机器上，比如：挂载一个共享文件系统。

fsimage/edits 是序列化后的文件，想要查看或编辑里面的内容，可通过 HDFS 提供的 oiv\oev 命令，如下：

  • 命令: hdfs oiv（offline image viewer），用于将 fsimage 文件的内容转储到指定文件中以便于阅读，如文本文件、XML文件，该命令需要以下参数：
    • -i（必填参数）–inputFile 输入FSImage文件
    • -o（必填参数）–outputFile 输出转换后的文件，如果存在，则会覆盖
    • -p (可选参数） –processor 将FSImage文件转换成哪种格式：（Ls | XML | FileDistribution），默认为Ls
  • 命令：hdfs oev（offline edits viewer），该工具只操作文件因而并不需要 Hadoop 集群处于运行状态。支持的输出格式有 binary（Hadoop使用的二进制格式）、XML（在不使用参数 p 时的默认输出格式）和 stats（输出 edits 文件的统计信息）

示例：

1
2
3
hdfs oiv -i /data1/hadoop/dfs/name/current/fsimage_0000000000019372521 -o /home/hadoop/fsimage.txt

hdfs oev -i edits_0000000000000042778-0000000000000042779 -o edits.xml

小结

  • NameNode 管理着 DataNode，接收 DataNode 的注册、心跳、数据块提交等信息的上报，并且在心跳中发送数据块复制、删除、恢复等指令；同时，NameNode 还为客户端对文件系统目录树的操作和对文件数据读写、对 HDFS 系统进行管理提供支持。
  • NameNode 启动后会进入一个称为安全模式的特殊状态。处于安全模式的 NameNode 是不会进行数据块的复制的。NameNode 从所有的 DataNode 接收心跳信号和块状态报告。块状态报告包括了某个 DataNode 所有的数据 块列表。每个数据块都有一个指定的最小副本数。当 NameNode 检测确认某 个数据块的副本数目达到这个最小值，那么该数据块就会被认为是副本安全 (safely replicated) 的；在一定百分比（这个参数可配置）的数据块被 NameNode 检测确认是安全之后（加上一个额外的 30 秒等待时间）， NameNode 将退出安全模式状态。接下来它会确定还有哪些数据块的副本没 有达到指定数目，并将这些数据块复制到其他 DataNode 上。

Secondary NameNode

在 HA cluster 中又称为 standby node。

  • 定期合并 fsimage 和 edits 日志，将 edits 日志文件大小控制在一个限度下
  • NameNode 响应 Secondary NameNode 请求，将 edit log 推送给 Secondary NameNode，并且自己开始重新写一个新的 edit log
  • Secondary NameNode 收到来自 NameNode 的 fsimage 文件和 edit log
  • Secondary NameNode 将 fsimage 加载到内存，应用 edit log ， 并生成一个新的 fsimage 文件
  • Secondary NameNode 将新的 fsimage 推送给 NameNode
  • NameNode 用新的 fsimage 取代旧的 fsimage ，在 fstime 文件中记下检查点发生的时间

HDFS 写文件

  1. Client将FileA按64M分块。分成两块，block1和Block2;
  2. Client向nameNode发送写数据请求，如图蓝色虚线①
  3. NameNode节点，记录block信息。并返回可用的DataNode，如粉色虚线②
    • Block1: host2,host1,host3
    • Block2: host7,host8,host4
  4. client向DataNode发送block1；发送过程是以流式写入，流式写入过程如下：
    4.1 将64M的block1按64k的packet划分
    4.2 然后将第一个packet发送给host2
    4.3 host2接收完后，将第一个packet发送给host1，同时client想host2发送第二个packet
    4.4 host1接收完第一个packet后，发送给host3，同时接收host2发来的第二个packet
    4.5 以此类推，如图红线实线所示，直到将block1发送完毕
    4.6 host2,host1,host3向NameNode，host2向Client发送通知，说“消息发送完了”。如图粉红颜色实线所示
    4.7 client收到host2发来的消息后，向namenode发送消息，说我写完了。这样就真完成了。如图黄色粗实线
    4.8 发送完block1后，再向host7，host8，host4发送block2，如图蓝色实线所示

说明

当客户端向 HDFS 文件写入数据的时候，一开始是写到本地临时文件中。假设该文件的副 本系数设置为 3 ，当本地临时文件累积到一个数据块的大小时，客户端会从 Namenode 获取一个 Datanode 列表用于存放副本。然后客户端开始向第一个 Datanode 传输数据，第一个 Datanode 一小部分一小部分 (4 KB) 地接收数据，将每一部分写入本地仓库，并同时传输该部分到列表中 第二个 Datanode 节点。第二个 Datanode 也是这样，一小部分一小部分地接收数据，写入本地 仓库，并同时传给第三个 Datanode 。最后，第三个 Datanode 接收数据并存储在本地。因此， Datanode 能流水线式地从前一个节点接收数据，并在同时转发给下一个节点，数据以流水线的方式从前一个 Datanode 复制到下一个，时序图如下：

小结

  • 写入的过程，按hdsf默认设置，1T文件，我们需要3T的存储，3T的网络流量
  • 在执行读或写的过程中，NameNode和DataNode通过HeartBeat进行保存通信，确定DataNode活着。如果发现DataNode死掉了，就将死掉的DataNode上的数据，放到其他节点去。读取时，要读其他节点去
  • 挂掉一个节点，没关系，还有其他节点可以备份；甚至，挂掉某一个机架，也没关系；其他机架上，也有备份

HDFS 读文件

  • 客户端通过调用FileSystem对象的open()方法来打开希望读取的文件，对于HDFS来说，这个对象时分布文件系统的一个实例；
  • DistributedFileSystem通过使用RPC来调用NameNode以确定文件起始块的位置，同一Block按照重复数会返回多个位置，这些位置按照Hadoop集群拓扑结构排序，距离客户端近的排在前面 (详见第三章）
  • 前两步会返回一个FSDataInputStream对象，该对象会被封装成DFSInputStream对象，DFSInputStream可以方便的管理datanode和namenode数据流，客户端对这个输入流调用read()方法
  • 存储着文件起始块的DataNode地址的DFSInputStream随即连接距离最近的DataNode，通过对数据流反复调用read()方法，将数据从DataNode传输到客户端
  • 到达块的末端时，DFSInputStream会关闭与该DataNode的连接，然后寻找下一个块的最佳DataNode，这些操作对客户端来说是透明的，客户端的角度看来只是读一个持续不断的流
  • 一旦客户端完成读取，就对FSDataInputStream调用close()方法关闭文件读取

Block 持续化结构

DataNode节点上一个Block持久化到磁盘上的物理存储结构，如下图所示：

每个Block文件（如上图中blk_1084013198文件）都对应一个meta文件（如上图中blk_1084013198_10273532.meta文件），Block文件是一个一个Chunk的二进制数据（每个Chunk的大小是512字节），而meta文件是与每一个Chunk对应的Checksum数据，是序列化形式存储